A  Gentle  Introduction  to 
Object-Oriented  Software  Principles 

Maj.  Christopher  Bohn,  Ph.D.,  and  John  Reisner 
Air  Force  Institute  of  Technology 

For  many  of  today’s  software  professionals,  the  concepts  behind  object-oriented  (00)  software  principles  are  as  familiar  as  the 
tips  of  their fingers;  for  others,  this  is  not  the  case.  If  you  are  a  structured-programming  developer  who  is  beginning  to  suspect 
that  00  is  not  simply  the flavor-of-the-decade,  or  if  you  are  the  program  manager  of  a  software-intensive  system  who  has  never 
written  code,  you  may  be  wondering:  Just  what  is  this  00  paradigm?  This  article  will  help  you  find  that  answer. 


The  notion  that  an  object  is  an  instantiat¬ 
ed  member  of  a  class  is  a  comfortable  and 
familiar  one  to  Generation  X  programmers 
who  were  educated  in  the  1 990s  and  to  pro¬ 
grammers  with  Ada95,  C++,  or  Java  expe¬ 
rience.  However,  to  those  who  have  back¬ 
grounds  replete  with  Pascal,  COBOL,  or 
FORTRAN  skills,  the  OO  paradigm  can  be 
intimidating,  confusing,  or  even  exasperat¬ 
ing.  If  you  examine  OO  code,  the  con¬ 
structs  seem  familiar  enough:  declarations, 
loops,  functions,  and  procedures.  So,  what 
about  OO  development  is  so  vastly  differ¬ 
ent,  unique  enough  that  it  even  has  been 
designated  as  a  new  paradigm? 

In  a  nutshell,  the  OO  approach: 

...  encapsulates  data  with  corre¬ 
sponding  operations  and  employs 
polymorphic  mechanisms  such  as 
class  inheritance.  With  data  encap¬ 
sulation,  object  classes  can  be  con¬ 
veniently  reused,  modified,  tested, 
and  extended.  [I] 

This  quote,  while  a  concise  summary  of  the 
paradigm,  is  laden  with  OO-speak,  provid¬ 
ing  little  help  to  the  curious  neophyte. 

This  article  explains  several  key  aspects 
of  OO  software  -  abstraction,  encapsula¬ 
tion,  information  hiding,  decentrali2ed 
problem  solving,  inheritance,  polymor¬ 
phism,  and  reuse  —  with  the  aim  of  pre¬ 
senting  a  clear  overview  and  summary  of 
the  unique  strengths  of  object-oriented 
software  development. 

Abstraction 

Abstraction  is  a  term  used  to  describe  putting 
certain  parts  of  a  system  in  a  black  box;  that 
is,  to  ignore  the  implementation  details  of 
that  subsystem.  We  frequently  use  abstrac¬ 
tion  in  everyday  life:  We  start  our  automo¬ 
biles  without  thinking  about  ignition  sys¬ 
tems  or  internal  combustion,  we  send  doc¬ 
uments  to  printers  without  fuUy  under¬ 
standing  spoolers  and  queues  in  the  net¬ 
work. 

With  abstraction,  system  developers  do 
not  need  to  think  about  systems  in  their  full 
complexity.  It  would  be  the  rare  automobile 


designer  who  could  simultaneously  keep 
track  of  details  about  the  exhaust  manifold 
and  the  seat  belt  buckle;  similarly,  software 
developers  need  to  abstract-away  details  of 
some  parts  of  the  system  while  focusing  on 
others.  Also,  with  abstraction,  code  can  be 
reused  without  full  knowledge  of  the 
reused  component.  Instead,  we  can  focus 
on  an  abstract  mental  model  of  the  com¬ 
ponent’s  expected  behavior,  which  we  will 
refer  to  as  its  cover  story  or  contract.  As  long  as 
reused  code  maintains  the  cover  story,  and 
as  long  as  it  does  not  violate  its  contract,  it 
does  not  matter  how  its  task  is  accom¬ 
plished.  Again,  consider  the  automobile 
designer:  Subsystems  that  rely  on  the  cor¬ 
rect  operation  of  an  engine  can  be  designed 
to  work  regardless  of  whether  ignition  tim¬ 
ing  is  accomplished  with  a  mechanical  dis¬ 
tributor  or  by  using  an  electronic  timing 
mechanism.  So  long  as  the  timing  works 
correctly,  the  cover  story  is  not  broken,  and 
the  system  will  work. 

Telling  programmers  that  they  do  not 
need  to  know  implementation  details  might 
make  them  uneasy.  Should  they  not  be  con¬ 
cerned  about  reliability,  supportability,  and 
efficiency?  Absolutely.  Abstraction  is  not 
used  to  integrate  shoddy  code  into  a  system 
under  the  guise  of  reuse.  Rather,  we  do  not 
need  to  know  the  details  because  the  contracts 
already  provide  sufficient  information 
about  the  expected  object  behavior.  The 
end  goal  is  to  have  a  software  architecture 
that  facilitates  both  substitution  and  reuse. 
This  also  helps  the  system  evolve  with  min¬ 
imal  collateral  damage  from  changes  {i.e.  we 
can  change  one  part  of  the  system  without 
having  to  change  others,  an  important  and 
recurring  theme  in  OO). 

Encapsulation 

Reuse  is  nothing  new  —  code  reuse  libraries 
have  been  around  for  decades.  But  in  OO, 
we  reuse  more  than  algorithms;  we  reuse 
classes. 

In  OO,  classes  and  objects  are  closely 
related;  an  object  is  a  particular  member  (or 
instance)  of  a  class.  Classes  are  a  kind  of  tem¬ 
plate,  providing  a  means  to  define  both  the 
state  and  behavior  oi  an  object. 


For  example,  a  car’s  state  might  be 
described  as  engine  running,  traveling  east  at  45 
mph,  with  a  total  of  150  miles  traveled.  We 
might  expect  the  possible  behaviors  of  a  car 
to  include  turning  the  engine  on,  turning 
the  engine  off,  moving  at  some  speed  and 
direction,  changing  the  speed  and  direction, 
and  retrieving  the  total  distance  traveled. 

Once  the  object’s  state  and  behavior  are 
described,  we  can  then  describe  a  class  of 
cars.  This  is  done  by  identifying  a  car’s  attrib¬ 
utes,  as  well  as  the  methods  (sometimes 
called  the  operations)  that  a  car  can  perform. 
An  example  of  this  is  shown  in  Figure  I. 

In  an  OO  software  system,  an 
Automobile  class  is  likely  to  look  quite  a  bit 
different  than  the  one  shown  in  Figure  I. 
After  all.  Defense  Advanced  Research 
Projects  Agency  (DARPA)  Grand 
Challenge  [2]  aside,  computers  do  not 
change  the  direction  and  speed  of  a  car;  dri¬ 
vers  do.  However,  consider  a  hypothetical 
information  system  for  a  state’s  bureau  of 
motor  vehicles.  Such  a  system  might  also 
model  a  class  for  automobiles,  but  it  would 
look  more  like  the  one  depicted  in  Figure  2. 

An  object  is  an  instance  of  a  class.  When 
we  create  a  new  instance,  the  attributes  of 
that  particular  object  will  take  on  specific 
values.  For  example,  if  someone  bought  a 
brand-new  Lexus  as  a  gift  for  their  spouse 
(like  on  those  holiday  commercials),  that 
would  necessitate  a  trip  to  the  license 
bureau,  where  a  friendly  clerk  would  instan¬ 
tiate  a  new  object  of  the  Automobile  class  type 
(actually,  the  clerk  would  do  this  unknow- 
ingly  -  thanks  to  abstraction  -  merely  by 
clicking  on  a  New  Registration  icon).  For 
this  instance.  Make  =  Lexus,  Model  = 
GS300,  Year  =  2007,  Color  =  Silver,  etc. 
The  attributes  of  a  class  are  analogous  to  a 
record  in  languages  such  as  Pascal,  while  the 
methods  of  a  class  are  implemented  as  pro¬ 
cedures  and  functions.  Collectively,  the  val¬ 
ues  of  the  attributes  define  the  object’s  state. 
Essentially,  the  attributes  and  methods 
jointly  implement  the  class’  contract:  They 
specify  what  information  the  object  con¬ 
tains,  as  well  as  its  expected  behavior. 

OO  systems  place  the  data  (the  attribut¬ 
es)  and  the  operations  that  use  that  data 
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(the  methods)  together.  Moreover,  the 
object’s  state  can  only  be  changed  by  using 
the  operations  defined  in  the  class. 
Organizing  software  systems  in  a  modular 
way  is  not  new  [3],  but  this  encapsulation  of 
attributes  and  methods  -  that  is,  the  group¬ 
ing  of  data  and  behavior  in  the  same  entity, 
as  opposed  to  them  being  dispersed 
throughout  the  system  —  is  a  key  differen¬ 
tiator  between  the  structured  and  object 
paradigms. 

Information  Hiding 

As  a  rule,  when  we  define  a  class,  we  speci¬ 
fy  that  the  methods  are  public  while  the 
attributes  are  private',  that  is,  objects  can  call 
the  methods  of  another  object,  but  no 
other  object  can  have  direct  access  to  the 
values  of  its  attributes.  This  means  that  the 
only  way  to  read  or  change  the  state  of  an 
object  ii.e.,  to  read  or  change  an  attribute’s 
value)  is  through  the  class’  methods. 

In  our  Figure  2  example,  we  can  assume 
that  the  Register  method  will  assign  initial 
values  to  all  of  the  attributes  (the  first  six 
likely  entered  by  the  clerk,  while  the  seventh 
might  be  automatically  generated  with  a  cal¬ 
endar  function,  e.g.,  one  year from  today’s  date). 
The  renew( )  method  will  only  affect  one 
attribute,  plateExpirationDate.  If  some 
other  scenario  requires  other  read  or  write 
access  to  the  variables,  then  methods  to 
perform  these  reads  or  writes  would  need 
to  be  added  to  the  class.  For  example,  we 
might  want  to  add  a  changeColor( )  meth¬ 
od,  so  that  if  an  auto  owner  repainted  his 
car,  that  change  could  be  reflected  in  the 
system  without  having  to  re-register  the 
vehicle.  However,  there  would  not  be  a 
change Year( )  method,  as  the  model-year  of 
an  automobile  would  not  change. 

Using  the  methods  to  access  the  attrib¬ 
utes  means  that  the  information  is  bidden  by 
a  public  interface,  [i.e.,  the  data  are  hidden 
behind  the  public  methods  of  the  class).  If 
the  information  were  not  hidden,  then 
another  object  could  directly  access  and 
change  an  Automobile  object’s  year,  either 
accidentally  or  by  design  causing  that  object 
to  break  its  cover  story  (the  modified  con¬ 
tract  states  that  Automobiles  can  be  regis¬ 
tered,  renewed,  and  re-painted,  but  not  arti¬ 
ficially  aged).  Returning  for  a  moment  to 
the  real-world  automobile  (Figure  I),  any¬ 
one  who  suspects  that  a  screwdriver  has 
been  used  to  tamper  with  a  car’s  odometer 
can  sympathize  with  the  perils  of  direct 
access  to  data  that  should  be  protected. 

In  the  realm  of  OO,  we  can  assume 
that  any  part  of  a  component  we  depend 
upon  will  always  behave  as  expected,  and 
that  no  other  part  of  the  system  will  cause 
our  part  to  violate  a  contract.  Encapsula¬ 
tion  and  information  hiding  keep  both  of 


these  assumptions  safe. 

Decentralized  Problem  Solving 

Thus  far,  our  examples  have  been  limited  to 
a  single  class  (i.e.,  the  Automobile  class).  In 
a  small-scale  system,  encapsulated  objects 
are  a  nifty  idea,  but  the  full  benefits  of  these 
assumptions  are  not  realized  until  a  system 
with  many  interacting  classes  is  designed. 

OO  software  uses  the  concept  of  mes¬ 
sage  passing  to  create  an  architecture  in 
which  objects  request  services  from  and 
provide  services  for  each  other.  When  you 
want  an  object  to  do  something,  you  invoke 
one  of  its  methods  by  passing  a  message.  This  is 
very  similar  to  making  a  procedure  or 
function  call.  However,  there  are  two 
notable  differences,  one  being  physical  (the 
called  code  resides  in  a  different  and  sepa¬ 
rately  compiled  module  from  the  calling 
code);  while  the  other  is  conceptual  (the 
method  invoked  is  part  of  a  class’  prede¬ 
fined  public  interface).  These  differences 
allow  us  to  design  systems  that  have  inter¬ 
acting  classes  of  objects  with  well-defined 
responsibilities.  In  a  vehicle  registration 
system,  such  an  architecture  may  not  yield 
much  of  benefits,  but  in  other  applications 
(such  as  a  windows-based  operating  sys¬ 
tem,  or  a  suite  of  gaming  software),  the 
potential  benefits  are  quite  high. 

Perhaps  more  importantly,  the  object 
paradigm  allows  us  to  create  decentralized 
solutions  to  computing  problems.  Decen¬ 
tralization  permits  us  to  solve  complex 
problems  that  we  could  not  solve  with  a 
centralized  solution.  For  example,  consider 
the  post  office.  If  the  clerk  behind  the 
counter  was  responsible  for  delivering 
every  incoming  piece  of  mail,  then  the 
postal  service  would  be  very  inefficient 
indeed.  Instead,  the  post  office  employs 
classes  of  people  and  machines  with  well- 
defined  responsibilities  -  clerks,  sorters. 

Figure  1:  A  Class  of  Automobiles,  Defined  By 
State  (Four  Attributes)  and  Behavior  (Six  Methods) 
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handlers,  deliverers  -  each  doing  their  part 
to  deliver  around  100  billion  pieces  of 
mail  annually  [4]. 

Inheritance 

In  the  course  of  developing  OO  software, 
we  often  find  that  we  need  a  class  of 
objects  that  specialises  an  existing  class.  For 
example,  a  Leased  Automobile  is  a  special 
type  of  automobile.  Besides  the  make, 
model,  and  other  attributes  that  every  auto¬ 
mobile  has,  a  leased  automobile  has  anoth¬ 
er  attribute:  the  lessor.  Another  special  type 
of  Automobile  is  a  state-owned  automo¬ 
bile.  Through  a  mechanism  called  inheritance, 
we  can  formalize  this  relationship.  We  call 
Automobile  the  parent  class  or  superclass, 
while  LeasedAutomobile  and  StateAuto- 
mobile  are  known  as  child  classes  or  subclasses. 
This  is  sometimes  called  the  is-a  relation¬ 
ship:  a  LeasedAutomobile  is-a  kind  of 
Automobile.  Everything  that  is  true  about  a 
parent  class  is  also  true  about  its  child 
classes;  the  special  types  of  automobiles 
have  all  the  same  attributes  and  operations 
as  a  standard  automobile.  Plus,  they  have 
additional  attributes  and/or  operations. 
For  example,  a  Leased- Automobile  also  has 
a  Lessor  attribute,  and  a  StateAutomobile 
has  a  scheduleMaintenance(  )  operation. 
The  attributes  and  operations  in  Auto¬ 
mobile  need  not  be  reproduced  in  its  sub¬ 
classes;  they  are  inherited. 

Another  simation  is  known  as  generalisa¬ 
tion.  For  example,  boats  also  need  to  be  reg¬ 
istered.  If  we  discover  that  there  are  many 
similarities  between  boats  and  automobiles, 
we  can  create  a  new  class.  Vehicle,  and  make 
Automobile  and  Boat  subclasses  of  Vehicle. 
The  commonalities  among  Automobile  and 
Boat  are  then  moved  into  the  Vehicle  super¬ 
class,  possibly  renaming  attributes  that  rep¬ 
resent  the  same  concept  by  different  names. 

Inheritance  leads  to  improved  reuse  and 
maintainability.  Because  subclasses  inherit  all 

Figure  2:  Another  Automobile  Class,  One  More 
Ukely  to  be  Found  in  an  Information  System 


Automobile 


vehicle I Dnumber 

make 

model 

year 

color 

plateNumber 

plateExpirationDate 


register ( ) 
renew  ( ) 


October  2006 


www.stsc.hill.af.mil  25 


Software  Engineering  Technology 


Figure  3:  An  Inheritance  Hierarckf  of  the  Vehick  Class 


the  attributes  and  operations  of  their  super¬ 
class,  they  automatically  get  aH  the  debugged 
functionality  that  is  already  in  their  parent 
class.  When  creating  a  child  class,  we  need 
only  concentrate  on  the  ways  in  which  the 
new  class  is  different  from  its  parent. 

Maintainability  improves  because  when 
a  change  is  made  to  a  parent  class,  then  the 
subclasses  (and  their  subclasses)  automati¬ 
cally  get  the  changes,  too.  Make  the  change 
in  one  place,  and  the  change  is  propagated 
through  the  entire  inheritance  hierarchy. 
Another  way  maintainability  is  improved  is 
through  isolation  of  the  subclasses.  If  a 
change  needs  to  be  made  for  only  one  spe¬ 
cialized  class,  then  those  changes  can  be 
made  without  any  risk  of  introducing  new 
errors  into  other  classes.  This  increased 
maintainability  is  even  more  beneficial  as 
code  evolves  over  time. 

Polymorphism 

Because  everything  that  is  true  about  a  par¬ 
ent  class  is  true  about  its  chM  classes, 
instances  of  the  child  classes  will  maintain 
their  parent’s  cover  story  as  their  own.  They 
wfll  have  a  richer  cover  story,  to  be  sure,  but 
they  should  not  break  the  cover  story  they 
inherited.  To  put  it  another  way,  their  con¬ 
tract  is  an  amendment  of  their  parent  class’ 


contract:  They  may  promise  a  little  more,  but 
they  win  also  honor  their  parent’s  contract. 

This  is  the  beginning,  but  not  the  end, 
of  the  concept  known  as  polymorphism. 
Recall  that  one  of  the  purposes  of  abstrac¬ 
tion  is  to  support  the  substitution  of  one 
component  with  another  that  honors  the 
first  component’s  contract.  Polymorphism 
is  a  special  form  of  substitution,  in  which 
the  component  to  be  used  may  not  be 
known  until  the  program  is  running. 

There  is  more  to  polymorphism  than 
simply  substituting  one  class  with  another 
that  has  a  few  extra  attributes  and  methods. 
When  we  create  a  subclass,  we  can  override 
some  of  the  methods  in  the  superclass. 
That  is,  the  method  has  the  same  name  and 
parameters  as  the  method  in  the  parent 
class,  but  actual  code  for  the  method  is  dif¬ 
ferent,  providing  the  behavior  appropriate 
for  the  particular  subclass.  Consider  the 
inheritance  tree  in  Figure  3;  we  have  marked 
with  an  asterisk  the  operations  that  are 
overridden  in  the  subclasses.  The  register( ) 
operation  has  been  overridden  by  Auto= 
mobile.  Boat,  and  LeasedAutomobile  so 
that  the  clerk  would  be  prompted  to  enter 
values  for  the  additional  attributes. 
StateAutomobile,  though,  reuses  the  regis- 
ter( )  operation  provided  by  its  parent  class. 


Similarly,  all  classes  except  LeasedAuto¬ 
mobile  reuse  the  renew( )  operation  provid¬ 
ed  by  Vehicle,  since  they  do  not  need  any 
special  behavior.  LeasedAutomobde,  how¬ 
ever,  overrides  renew(),  since  the  lessor  may 
need  to  be  consulted. 

When  the  software  expecting  a  Vehicle 
object  is  provided  an  object  whose  specific 
class  is  somewhere  in  Vehicle’s  inheritance 
hierarchy,  the  operations  appropriate  to  that 
object  win  be  invoked  automatically  (the 
details  of  how  this  happens  are  well  beyond 
the  scope  of  this  paper).  For  example,  if  an 
Automobile  object  is  registered,  the  code 
found  in  the  register( )  method  of  the 
Automobile  class  is  executed.  Flowever, 
when  a  LeasedAutomobile  object  is  regis¬ 
tered,  then  the  register( )  code  executed  is 
the  overriding  method  found  in  Leased 
Automobile.  This  selection  of  the  correct 
method  to  be  executed  occurs  automatical¬ 
ly,  without  any  embedded  if-then-else  or 
case  logic  required;  therein  lies  the  power  of 
polymorphism. 

Tying  It  All  Together 

The  concepts  presented  in  this  article  are 
often  difficult  to  grasp,  especially  in  a  single 
sitting.  Moreover,  people  who  are  just 
beginning  to  understand  these  concepts 
often  find  that  they  can  follow  an  OO 
designer’s  line  of  reasoning,  but  have  a 
more  difficult  time  when  it  is  their  turn  to 
try  it  out.  Some  authors  have  said  that  it 
takes  six  to  nine  months  of  experience  to 
become  proficient  in  fuUy  exploiting  OO 
techniques  [5].  Further,  the  impact  of 
adopting  an  OO  mindset  is  not  limited  only 
to  design;  indeed,  it  has  implications 
throughout  the  development  life  cycle, 
from  requirements  analysis  to  design,  to 
implementation  and  test,  and  on  through 
maintenance.  Volumes  could  be  (and  have 
been)  written  on  each  of  these  topics.  To 
become  more  familiar  with  the  breadth  and 
depth  of  OO  development,  we  recommend 
that  you  investigate  educational  opportuni¬ 
ties  from  a  reputable  continuing  education 
provider,  and  that  you  find  a  software  engi¬ 
neer  with  mature  OO  skills  to  serve  as  a 
mentor  as  you  grow  into  increasingly  larger, 
increasingly  critical  endeavors.  ♦ 

Additional  Reading 

If  you  are  interested  in  learning  how  the 
OO  approach  influences  the  software  life 
cycle,  you  may  want  to  start  with  these 
books.  Alistair  Cockburn’s  Writing  Effective 
Use  Cases  can  help  you  turn  your  functional 
requirements  into  use  cases,  which  will 
drive  the  rest  of  your  project’s  develop¬ 
ment;  Doug  Rosenberg’s  Use  Case  Driven 
Object  Modeling  with  UME-  A  Practical 
Approach  does  a  fine  job  of  describing  the 
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activities  you  would  use  to  begin  your 
design  from  those  use  cases.  Implementa¬ 
tion  issues  can  be  language-dependent,  but 
Steve  McConnell’s  Code  Complete  and 
Timothy  Budd’s  An  Introduction  to  Object- 
Oriented  Vrogramming  address  the  issues  as 
language-neutral  as  possible.  Paul 
Jorgensen’s  Software  Testing:  A  Craftsman’s 
Approach  is  a  good  book  for  testing  in  gen¬ 
eral,  and  the  last  five  chapters  specifically 
cover  object-oriented  testing.  Similarly, 
Thomas  Pigoski’s  Practical  Software 
Maintenance  covers  the  breadth  of  software 
maintenance,  with  a  chapter  dedicated  to 
OO’s  impact.  If  you’re  already  familiar  with 
OO  concepts,  you  may  want  to  look  at 
some  more  advanced  books,  such  as  Ken 
Pugh’s  Prefactoring,  Joshua  Kerievsky’s 
Refactoring  to  Patterns,  and  David  Astel’s  Test- 
Driven  Development:  A  Practical  Guide. 
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What  Science  Fiction  Authors  Got 
Wrong,  and  Why  We’re  Better  Off  For  It 
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Air  Force  Institute  ofTechnology 

Computers  are  commonplace  today,  and  they  have  changed  much  of 
the  way  we  go  about  our  lives,  saving  time  and  money.  Surprisingly, 
as  much  as  classical  science  fiction  authors  were  visionaries,  they  did 
not  foresee  the  arrival  ofi  the  digital  computer  and  its  influence  on 
modern  life. 

Robert  Heinlein  once  had  a  discussion  with  a  professional 
astronomer  in  which  the  conversation  turned  to  Heinlein’s  atten¬ 
tion  to  detail.  Heinlein  recounted  how,  when  writing  Space 
Cadet  (1948),  he  and  his  wife  used  yards  of  butcher  paper  over 
three  days  to  calculate  a  particular  orbit;  the  results  were  described 
in  the  story  with  one  line  of  text,  but  it  was  necessary  to  drive  the 
drama.  When  the  astronomer  wondered  why  Heinlein  did  not 
use  a  computer  to  make  the  calculation,  he  replied.  My  dear  boy, 
this  was  1947. 


Of  course,  computers  are  commonplace  today,  and  they  have 
changed  much  of  the  way  we  go  about  our  lives,  saving  time  and 
money.  Surprisingly,  as  much  as  Heinlein  and  other  Golden  Age 
science  fiction  authors  were  visionaries  —  Heinlein,  for  example,  is 
credited  with  inventing  the  waterbed  and  tele-operated  manipu¬ 
lators  (waldoes),  and  with  heavily  influencing  spacesuit  design; 
none  of  them  foresaw  the  coming  of  the  digital  computer  and  its 
influence  on  modern  life. 

So  while  computers  are  everywhere  today,  Heinlein  did  not 
have  ready  access  to  computers  and  neither  did  his  characters.  In 
Starman  fones  (1953),  faster-than-light  travel  is  possible  by  enter¬ 
ing  hyperspace  singularities  on  precise  vectors.  Computing  course 
corrections  to  get  the  spaceship  on  the  correct  vector  required 
astrogators  to  make  rapid  calculations  making  use  of  mathemati¬ 
cal  tables  and  a  computer  that  amounted  to  little  more  than  a  4- 
function  calculator.  Heinlein,  a  former  naval  officer,  no  doubt  was 
drawing  an  analogy  with  mathematical  tables  classically  used  to 
navigate  seaships  (Interestingly,  Charles  Babbage  was  inspired  to 
develop  a  mechanical  computer  in  the  19  th  century  while  review¬ 
ing  errata  for  a  set  of  mathematical  tables  for  celestial  navigation). 
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